home *** CD-ROM | disk | FTP | other *** search
/ Gamers Delight 2 / Gamers Delight 2.iso / Aminet / game / role / AMSrv_0_9.lha / AMSrv / Doc / SMUD.txt < prev    next >
Text File  |  1995-01-21  |  5KB  |  109 lines
  1. AmigaMUD, Copyright 1995 by Chris Gray
  2.  
  3.  
  4.             The 'SMUD' Client Program
  5.  
  6. The SMUD program is a simple text-only client for use with an AmigaMUD
  7. server running on the same machine. It can be run only from a shell
  8. since it relies on standard input and output working. SMUD is good for
  9. quick runs since it is much smaller than the full 'MUD' client
  10. program. SMUD can also be valuable on a system with limited memory. I
  11. typically use SMUD for compiling the standard scenario, with
  12.  
  13.     SMUD <st:go
  14.  
  15. where 'st:' is an assign to the directory containing the scenario
  16. sources, and 'go' is a small source file there that mainly just
  17. sources all the rest of the files in the correct order. I also use
  18. SMUD for quick SysAdmin runs.
  19.  
  20. SMUD accepts a few flags on the command line:
  21.  
  22.     -a - tells SMUD that the device it is talking to is not an Amiga
  23.     console device or other device that accepts ANSI control
  24.     sequences. SMUD will then not try to blank passwords.
  25.  
  26.     -r - tells SMUD that it is running remotely. This disables its
  27.     ability to run an editor. If a BBS system uses SMUD to allow
  28.     text-only connections through some kind of pipe device, it
  29.     should specify this flag.
  30.  
  31.     -T - tells SMUD to use 'MUD test port' as the name of the port to
  32.     connect to the AmigaMUD server on.
  33.  
  34.     -N <name> - use <name> as the name of the character for the the
  35.     first playing session, rather than prompting for a name.
  36.  
  37.     -W <word> - use <word> as the password for the first playing
  38.     session. If it is incorrect, it counts as the first attempt,
  39.     and only two attempts remain. This is normally used in
  40.     conjunction with -N, but can be used without it.
  41.  
  42.     -t<value> - use value as an inactivity timeout. If no user input
  43.     occurs after the given interval (which is given in minutes),
  44.     then the client will be disconnected from the server.
  45.     Unfortunately, since there is no way to abort a Dos read
  46.     request, SMUD itself cannot exit until its pending read
  47.     request returns. Using the -p flag allows the timeouts to work
  48.     correctly, but at the expense of continual extra system load.
  49.  
  50.     -f<value> - the given decimal number is passed to "mud.library"
  51.     to control some client caching. There must be no spaces
  52.     between the 'f' and the value. The value is the sum of the
  53.     following:
  54.  
  55.         1 - cache procs. SMUD will cache the definitions (but not
  56.         the bodies) of builtin and user procs in the AmigaMUD
  57.         language. This saves refetching them when parsing
  58.         procs (such as after editing one).
  59.  
  60.         2 - cache symbols. SMUD will cache the values of symbols
  61.         that it has fetched from the server. Again, this cuts
  62.         down on communications when parsing AmigaMUD procs.
  63.  
  64.     Note that both of these flags increase the amount of memory
  65.     consumed by SMUD. This memory is not freed until SMUD exits.
  66.     The default value of 'FLAGS' is 3, i.e. both caches on. Note
  67.     that this is the opposite of the default for the full MUD
  68.     client program.
  69.  
  70.     -p - this flag puts SMUD into a polling mode. Normally SMUD uses
  71.     the standard Amiga asychronous I/O using DOS packets. This
  72.     latter is the proper way to do I/O on the Amiga.
  73.     Unfortunately, the console.device does not respond to a
  74.     request to abort an outstanding read request. This means that
  75.     when the server uses "NukeClient" to shut down a client that
  76.     is connected via SMUD, SMUD itself cannot exit until that read
  77.     request is satisfied (typically by the user hitting RETURN).
  78.     In polling mode, there is no outstanding read request - SMUD
  79.     continually (every 1/10 second) checks for available
  80.     characters, and will only issue a read if characters are
  81.     available. This way, "NukeClient" can cause SMUD to exit, and
  82.     thus return back to a BBS which can drop the line. Note,
  83.     however, that this mode continually uses extra CPU time on the
  84.     host machine, whether the player is doing anything or not.
  85.  
  86.  
  87. SMUD is able to start up an external editor for editing strings and
  88. AmigaMUD procedures, just like the full MUD program. It also does this
  89. based on the "EDITOR" environment variable, and will default the
  90. editor name to be "Ed". If a scenario uses the enquiry routines to ask
  91. about the nature of the effects available on a SMUD client, it will
  92. reply with all empty and zero values.
  93.  
  94. SMUD uses the Amiga OS packet interface to do asynchronous I/O with
  95. its standard input and output connection. It does not use "RAW" mode
  96. on a console screen. It is possible to call up SMUD from a BBS system
  97. which is not capable of calling up the full MUDAgent program. This
  98. will allow users of that BBS to access AmigaMUD, but they will not get
  99. the graphics/audio/mouse capabilities. Some BBS operators will want to
  100. use the -p option when doing this, so that they can boot players out
  101. of the SMUD program. This also allows the inactivity timeout to
  102. operate.
  103.  
  104. SMUD requires a stack of at least 10000 bytes. It will exit right away
  105. if the stack is less than that size. Use the shell 'Stack' command to
  106. setup a larger stack. When parsing extremely deeply nested AmigaMUD
  107. code, an even larger stack might be needed, but I have not needed one
  108. for parsing all of the standard scenario.
  109.